Una de las bases de las metodologías de desarrollo de software es definir cuándo una tarea ha sido realizada o terminada. Parece algo obvio pero muchas veces se fracasa debido a una mala estimación a causa de estimar tareas basadas en el tiempo medido entre su inicio y cuando se dice que se ha terminado.
Leer más =>>
Así se titula el primer libro de Raúl Herranz, uno de los profesores acreditados de Scrum Manager. El documento es libre y gratuito y puede descargarse de la siguiente dirección:
Leer más =>>
Hace un tiempo, Juanse, un compañero de trabajo, me envió un enlace de un framework desarrollado por Evan Miller que se llama ChicagoBoss. Este framework ha sido concebido con Ruby on Rails en mente, no es de extrañar cuando a lo largo de toda la documentación, se hacen referencias a cosas de Ruby on Rails, y las similitudes son tan extraordinariamente grandes, para ser dos lenguajes bastante diferentes.
Leer más =>>
Leyendo un artículo de Martin Fowler, sobre el tema Inversión de Control (en inglés), comenzando por el final, la etimología de la frase (entendido como el origen del concepto), se comenta que, en un principio (sobre los años 80) la gente se refería a una nueva forma de hacer las cosas como el Principio de Hollywood, teniendo presente la famosa frase de los cineastas: no nos llames, nosotros te llamaremos.
Si pensamos en las librerías, en cualquier lenguaje, ya sean módulos, paquetes u objetos, siempre alcanzamos una funcionalidad encapsulada dentro de una forma específica a la que se la puede llamar para realizar una acción. Pero esto cambia radicalmente en los frameworks, u entornos de desarrollo, ya que estos entornos, normalmente, realizan un cierto trabajo, y te permiten extender esa funcionalidad base, con ciertas reglas, a través de código que se escribe.
Leer más =>>
Cuando comencé a leer libros sobre Extreme Programming, me llamó la atención una de las propiedades de esta metodología de desarrollo, que era la propiedad del código.
Por mi parte he sido siempre muy comunista con respecto al código, no tengo el menor reparo en mirar, ampliar y corregir código de otras personas y dejo que los demás vean, opinen y corrijan y/o agreguen cosas a mis códigos... es la mentalidad del software libre.
Pero en las empresas ocurre lo contrario. Es muy normal, yo diría que incluso enfermizo, llegar a ver cómo cuando entras en una empresa en la que hay más de tres programadores, cómo cuando algo falla, cuando hay que hacer una nueva mejora, ampliación, adaptación, siempre dice uno en voz alta: ese código es de fulanito; indicando que ni lo va a ver, ni lo piensa modificar.
Leer más =>>
El tema de la calidad ha llenado páginas y páginas de la literatura informática en todos los idiomas. Es tal la necesidad de la búsqueda de la calidad, que hay estudios, técnicas y departamentos dentro de empresas e incluso empresas dedicados a establecer parámetros de calidad a los productos y proyectos que se realizan en las empresas de desarrollo de software.
Dentro del tema de la calidad, visto como un amplio abanico de elementos que la conforman, nos topamos con uno bastante confuso y complejo al principio: la calidad interna.
Leer más =>>
En este blog he escrito bastante sobre estos temas, y ahora, después de haber terminado de leer un gran libro, escrito sobre uno de los autores que más ha aportado a estas metodologías con su trabajo incansable, hablo de Henri Kniberg, me complace poder aconsejar la lectura de este libro, que se puede descargar libremente.
Leer más =>>
Ayer dicté la conferencia con el nombre del título de este post en la Universidad de Córdoba ante unos 40 alumnos y algunos profesores de la misma universidad.
Las metodologías ágiles no es un tema muy de moda en los ambientes académicos y universitarios, puesto que el desarrollo de software no es algo que se haga de forma práctica en esos entornos (se realizan más actividades de tipo docente e investigación), por lo que el tema les sonó a todos nuevo y fresco.
Leer más =>>
Este es uno de esos libros pioneros que hacen que nos planteemos muchas de las cosas que hacemos y, sobretodo, el cómo lo hacemos.
Leer más =>>
Un año y medio después de haber comenzado con las tecnologías y metodologías ágiles, no tengo más que recomendar el libro que me ayudó a comenzar y que ha sido una guía durante todo este tiempo.
Leer más =>>
Ayer leí un email de la lista de TDD en la que se anunciaba el publicación del libro TDD de Carlos Ble.
Es de agradecer que se haya publicado en castellano un libro sobre esta metodología (o técnica) de programación que es el desarrollo dirigido por pruebas (o test driven development). Casi que puedo asegurar que es el único libro escrito hasta el momento en castellano sobre este tema, que ya abordaba hace muchos años Kent Beck, en su libro Xtreme Programming Explained.
Leer más =>>
La técnica de pomodoro al igual que GTD (getting things done) o ZTD (zend to done), son técnicas para realizar las tareas diarias de forma ordenada y evitando distracciones.
Esta técnica debe su nombre a un reloj de cocina con forma de tomate (pomodoro), ya que, la propia técnica se basa en la medición del tiempo con un cronómetro, como los utilizados en la cocina.
Leer más =>>
El término de entrenador (coach) de desarrollo de software es un papel que suele ser muy importante en el quehacer diario de una empresa que tiene desarrollos de software, ya sean internos o para clientes externos.
Leer más =>>
El manifiesto ágil fue fruto de una reunión que se mantuvo en Salt Lake City en marzo de 2001. Diecisiete críticos de los modelos de mejora del desarrollo del software basado en procesos, convocados por Kent Beck, padre del Xtreme Programming, escribieron el siguiente manifiesto:
Leer más =>>
Después de haber aplicado un alto porcentaje de Scrum en los proyectos de software en los que trabajo, siento curiosidad por todas las demás metodologías ágiles que existen, sobre todo, para saber si hay alguna práctica que pueda emplear que me permita optimizar algún aspecto de la actividad diaria a desarrollar.
En este aspecto, he descubierto en Kanban un interesante aliado para aspectos de la metodología que quedaban algo descolgados, y son los procesos rutinarios, o solo tener presente la continuidad de las tareas, ya que las tareas que se realizan en Kanban pueden aparecer en el backlog en cualquier momento e ir haciéndose, según su importancia y/o prioridad.
Leer más =>>
Leyendo un artículo de una página de una empresa suiza (Crisp), he visto a lo que se refiere la planificación de póker. Voy a traducir gran parte del artículo para explicarlo.
Leer más =>>
Mi última entrada sobre Scrum, hablaba de la implementación del gráfico Burndown, de esto hace ya casi 3 meses, aunque realmente, comenzamos la andadura en algo antes.
En principio, tengo que tener presente que he estado usando algunas otras metodologías, como la Espiral de Boehm y Metrica-3, con lo que, he podido ver y sufrir en mis propias carnes, lo que significa e implica usar una metodología ágil, las ventajas que aporta y lo fáciles que tienden a ser, realmente.
Leer más =>>
Citando a Kent Beck, de su libro Extreme Programming Explained:
Leer más =>>En La Gente del Bosque y La Gente de la Montaña, el antropólogo Colin Turnbull dibuja el contraste de dos sociedades. En las montañas, los recursos eran escasos y la gente estaba siempre al borde de la hambruna. La cultura a la que evolucionaron era horrible. Las madres abandonaban a sus bebés, los entregaban a hordas de niños salvajes errantes en cuanto tenían opciones mínimas de sobrevivir. Violencia, brutalidad y traición estaban a la orden del día.
El desarrollo orientado a pruebas (TDD, test driven development) es una forma de desarrollar basándose en que un cierto algoritmo responda de una forma específica a unos datos específicos. Para explicar mejor esto, voy a explicar primero el enfoque tradicional y luego expongo las mejoras que introduce esta forma.
Leer más =>>
En estos días, después de haber pasado más de 24 horas en el último Sprint, sin descansar, donde comenté la experiencia de haber usado Scrum y XP en [otro artículo][1], volvemos a la carga.
Esta vez, con dos semanas de Sprint, bastante más tiempo, podemos realizar algunas técnicas más para poder medir cuánto vamos a tardar realmente en terminar el proyecto que tenemos entre manos.
Leer más =>>
Hace un tiempo escribí sobre Srum y XP, en ese mismo artículo, comentaba que estas técnicas, tanto Scrum como XP, eran dos técnicas que me gustaban mucho y que probaría en un futuro... bueno, pues ese futuro ya es presente :-)
La semana pasada, tuvimos, en la empresa en que trabajo, la presión de entregar un proyecto de forma rápida. Pensé que, en estos casos, lo que más se necesita es, como no, la organización. No se puede estar haciendo una actividad de desarrollo entre varias personas y estar con la cabeza preguntando siempre: ¿qué queda por hacer?; así que, me lancé, cogí dos tacos de post-it, uno de tamaño normal para las partes a desarrollar y otro de tamaño más pequeño, para las tareas que hay dentro de cada una de las partes.
Leer más =>>
Después de darle un repaso al libro Scrum y XP desde las trincheras, he visto que muchas de las técnicas en las que se basa, son como las que usaban nuestros profesores dinámicos en el colegio para motivarnos a participar en clase.
En esencia, es eso, que cada analista/programador se involucre en lo que está haciendo, llegue a un diseño y una finalidad y, sobre todo, que la información sobre lo que se hace, fluya sin que las interrupciones hagan que el trabajo se pare.
Leer más =>>